home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / aprs505u.zip / README.OPS < prev   
Text File  |  1994-06-11  |  18KB  |  272 lines

  1. README.OPS                APRS OPERATIONS NOTES
  2.  
  3.    The following discussionm may help you to understand the finer points of
  4. operating an APRS net.  It covers the two categories of operations.  Routine
  5. and Special event.  Also read the section on OBJECTS since the information
  6. there applies to both cases.  Since APRS was designed to facilitate real-
  7. time tactical communications, operating APRS on a routine basis is sometimes
  8. about as exciting as watching the grass grow!  The reason for building a
  9. routine APRS net is primarily for operator training and familiarity.  If your
  10. operators are not familiar with APRS in a benign environment, then they will
  11. not be able to use it in a crisis!
  12.  
  13. GATEWAY RULES:  I have interjected this paragraph because of the large number
  14. of APRS HF to VHF gateways now in operation.  First, it is very important that
  15. users understand that GATEWAYS ARE ONLY INTENDED TO LINK HF ACTIVITY INTO
  16. LOCAL VHF NETS.  IT IS INNEFFICIENT, DISCOURTEOUS, AND OFTEN ILLEGAL TO LINK
  17. from VHF to HF.  The illegality comes about if the GATEWAY is unattended.
  18. With current hardware, a gateway sysop cannot selectively restrict the VHF
  19. input, so it is incumbent on users to respect this deficiency and NOT put the
  20. sysop of the gateway at risk.  Linking HF operations into every local VHF
  21. APRS net in the country is not a problem, because the slow 300 baud data rate
  22. could never saturate ANY 1200 baud local net.  HOWEVER, linking just ONE
  23. active VHF net ANYWHERE in the country out onto HF WOULD CERTAINLY 100% BLOCK
  24. ALL HF OPERATIONS NATIONWIDE!  The capability is there for linking special
  25. events on VHF out for the entertainment of all HF listeners, but DO NOT ABUSE
  26. IT, OR WE WILL LOOSE IT!  See README.HF for suggested frequencies.
  27.  
  28.  
  29. DIGIPEATER RULES:  The advantages of APRS are many, but there is a price. 
  30. Since APRS uses a fixed digipeater path sometimes different for different
  31. stations depending on geographic location, there is a duplication of on the
  32. air packets.  This assures that all stations in the net are maintained up to
  33. date, but also proves to be less efficient during intense operator-to-operator
  34. QSO's where this point-to-point traffic is still being unnecessarily broadcast
  35. to all stations in the net.  For this reason, APRS operators should consider
  36. using TNC TALK mode (connected) to do intense one-on-one keyboard QSO's. 
  37. Especially if a direct connect without using APRS digipeaters is possible! 
  38. See README.MCM for lessons learned at the Marine Corps Marathon.  Many
  39. imporvements were made in version 2.13 to reduce the APRS packet QRM by at
  40. least a factor of four as a result!
  41.  
  42.  
  43. ACKS THAT DONT MAKE IT:  Just like connected packet, the chance of a message
  44. packet getting through is usually the same as the chance that the ACK will
  45. get back.  If the radio path is only giving a 50% chance of a packet getting
  46. through, that means that the receiver will probably get the message by the
  47. second transmission, but that the sender may not get an ACK until after his
  48. fourth transmission!  This is because the sender had to send 4 packets to get
  49. two through and the receiver then ACKed twice in order to get one through.
  50. You see this effect frequently on APRS, when you are communicating with a
  51. station over a long poor path.  You will notice that the person at the other
  52. end has already responded to your message even before you get an ack.  BUT
  53. your next line will never go out UNTIL it gets that ACK.  The reason that
  54. you will probably get his response message before your ack, is because his
  55. response message is being repeated over and over in the usual APRS decayed
  56. algorithm, but his ACK is ONLY transmitted once each time he gets a dupe of
  57. your message line to him.
  58.  
  59.     What this means is that whenever it is obvious that the other station has
  60. responded to your message line, you should ERASE it so that APRS will move on
  61. to the next line.  Sometimes if you know that the other station is probably
  62. hearing the digi better than the digi is hearing him, and you are not getting
  63. ACKS, then simply send him messages in the blind.  Let each line be transmitted
  64. for 6 minutes and then erase it.  APRS will then move on to the next line.
  65. Remember that APRS will have transmitted 6 times in the first 6 minutes, but
  66. that it will then be over 3 minutes, then 6 and then 12 minutes for further
  67. transmissions.
  68.  
  69.     Watching this effect of lost ACK responses on HF this summer between the
  70. 25 Naval Academy boats running APRS on HF, I made a significant change in
  71. APRS503a.  Now when APRS recognizes a duplicate message, it sends out the
  72. usual ACK, but stores a copy for transmisssion in the blind 30 seconds later.
  73. The reason for the 30 second delay is to avoid cluttering up the frequency
  74. if the path is good, since the sending station will have sent the message
  75. at least twice in the first 30 seconds.  After the third transmission, it is
  76. clear that the ACKs were lost and it is time to double up.  This simple
  77. change to the ACKING process has the potential of doubling throughput on a
  78. poor channel!
  79.  
  80.  
  81. SHORT MESSAGES:  As with any packet, especially on HF, the shorter the packet
  82. the better the chance of getting through.  Since a packet often has about
  83. 25 characters of overhead, however, there is not much sense of making the
  84. message part much shorter than a half line (40 characters).  The chance of
  85. a 40 character line getting clobbered compared to a 75 character line is
  86. 65%.  On HF (under poor conditions), keep 'em short.  A neat trick that I
  87. frequently use whenever I know that a station is not currently on the air, or
  88. the path is not currently good, is to send the first message line with only
  89. the word "testing".  THen I type my lengthy several line message and walk
  90. away.  THis way, only the very short "testing" line is transmitted (often
  91. for hours on HF) until the band opens, and then once the station ACKs that
  92. line, my remaining lines are transmitted.
  93.  
  94.      One last suggestion on HF and other poor paths that will make messages
  95. more sensible to the receiving station is to indicate to the receiver of a
  96. multiple line message that there are more lines to follow.  I use the >
  97. character to indicate that there is more to follow.  Without this, and by
  98. sending short lines, often it is not clear to the receiver that more is
  99. comming.  Often he tries to respond to my half sentences and then we spend
  100. twice as much time clarifying what in the world I am trying to say!  Another
  101. way to do it if you know how many lines you will be sending about the same
  102. subject is to indicate what line number it is out of the total.  For example,
  103. in a four line message, end the each line with >1/4, >2/4, >3/4, .4/4.
  104.  
  105.  
  106. ROUTINE OPERATIONS:  The APRS default digipeater path of RELAY is ok for a few
  107. users starting up an APRS net, but you will soon need to focus on a few good
  108. stations to serve as WIDE area digipeaters.  The reason for this is obvious.
  109. As soon as you get 3 or more local stations on APRS, any station living equi-
  110. distant (RF wise) from two other stations will ALWAYS hear a collision of
  111. EVERY packet digipeated by both of those stations.  That is why, once your
  112. network begins to grow, you need to designate your path by specific callsign
  113. and designate certain high stations as permanent digipeaters.  If you put up
  114. a few good wide area digipeaters with the generic ALIAS of WIDE, the coverage
  115. of the network can be extended significantly.  It is important to keep generic
  116. WIDEs well separated (40 miles or more over smooth terrain) to minimize
  117. duplicate repeats (or you end up with the same collison problem but on a larger
  118. scale).  Most users should be able to hit at least one of these WIDEs.  Just
  119. like with the RELAY's, however, users should use the specific digipeater call
  120. instead of the generic WIDE in routine cases to minimize collisions.
  121.  
  122.    All users must understand that they are responsible for setting their
  123. outgoing VIA path so that their packets hit the intended area of interest.
  124. Unlike normal CONNECTED protocols which automatically return ACKS via the
  125. reverse path of incomming packets, APRS is an unconnected broadcast protocol
  126. only and each station's packets will only go via the outgoing path set up by
  127. that station.  In version 2.13, if your station receives a duplicate APRS MSG
  128. packet more than 4 times, it gives you a beep and an alert that your ACK's are
  129. probably not being heard by the other station and that you should check your
  130. outgoing VIA path.
  131.  
  132.     Those stations between WIDE area digipeaters only need to use the single
  133. hop of WIDE and their packets will go in both directions.  Stations that can
  134. only hit one WIDE area station may set the path of WIDE,WIDE without any
  135. conflicts.  Paths of WIDE,WIDE,WIDE should be avoided for routine operations
  136. because it folds back on itself.  The same area can be covered by using
  137. WIDE,WIDE,W3XYZ where the unique call of the third digipeater is specifically
  138. specified.  If you think about it, stations at the end of an area can specify
  139. a pretty long string of digipeaters since the path is linear.  Stations in
  140. the middle can only specify a symetrical double hop with WIDE,WIDE before
  141. they have to begin favoring one direction or another with unique calls.
  142.  
  143. CAUTIONS ABOUT APRS MESSAGES:  Remember that the general condemnation of
  144. multiple digipeater hops in the packet community applies only to connected
  145. protocols.  This is because the probability of success goes down drastically
  146. because all ACKS must be successfully returned or all packets are repeated.
  147. This is generally NOT a problem with most APRS operations since only UI frames
  148. are used, and there are no acks.  HOWEVER, APRS one-line MSGS are ACKED, and
  149. the inefficiency of digipeaters DOES APPLY!  If you do a lot of one-line
  150. messages between operators, you will experience the same hopeless probabilities
  151. of success as with conventional packet.  (As noted above, in version 503a,
  152. APRS doubles up on ACKS on a poor channel and helps this situation somewhat.)
  153. But, in general, NEVER expect an APRS MSG to be successful beyond 2 digi's
  154. except if everyone else is DEAD.  Operator messages are a secondary function
  155. of APRS, and should not be used as a primary means of passing traffic!  One
  156. further caution, since APRS suspends all packet processing while waiting for
  157. the operator with a BLUE-BOXED prompt, never linger in a blue-box prompt. 
  158. The SEND command is a BLUE-BOXED prompt and should not be left un-completed!
  159.  
  160. OBJECTS:  As noted previously, anyone may place an object on the map and all
  161. other stations will see it.  In their systems, on their P-list, the object's
  162. position report will be marked with the last three letters of the station
  163. that is currently uplinking that position to the net.  A neat feature of APRS
  164. is that any station that has more current information on the location of that
  165. object can update its position by hooking, moving the cursor, and then
  166. hitting the insert key.  Now this new station begins uplinking the new posit,
  167. and all stations, will update their P-list entry for that object INCLUDING
  168. THE ORIGINAL UPLINK STATION!  The new position overwrites the old one so that
  169. the original station will now no longer uplink it.  This came in handy during
  170. hurricane tracking.  Who ever had information on the latest NWS EMILY
  171. position, uplinked it and everyone then always saw the latest storm track
  172. without anyone in the net being dependent on any one station for updates!
  173.  
  174.      Once objects are transmitted on to other station map screens, they will
  175. remain there until that operator deletes them.  Even if the original station
  176. stops sending the object position, it will remain there forever.  Once the
  177. object or station has not been heard from for 2 hours, it will fade to gray
  178. so that you know it is an old contact.  In version 4.01 a feature was added
  179. so that you can suppress the callsigns of old contacts.  Just press the J
  180. command, and select LATEST instead of selecting any specific object type.
  181. The result will be to redraw the map showing ALL symbols, but only the calls
  182. of the recent ACITVE stations less than 2 hours old.   Another feature added
  183. recently is the KILL function.  This permits the uplinker of an OBJECT to
  184. KILL it from all displays on the net.  His station will continue to uplink the
  185. object, but tagged with a special KILL flag to suppress its display on all
  186. screens.  It remains in everyone's P-lists, though, so they can refer back to
  187. it if needed.  They must still manually DELete it from their P-list as needed.
  188. Once the originator has KILLED an object, he should let it remain on his P-list
  189. for at least 4 minutes to be sure everyone has received the KILL indicator;
  190. then he can delete it from his list.
  191.  
  192.  
  193. SPECIAL EVENTS:  Let me use the Cycle Across Maryland (CAM) bike tour as an
  194. example of a special event which took a lot of daily APRS coordination.  We
  195. had two of three relief vehicles configured with GPS packet transponders.
  196. These were assembled in cake pan enclosures for duct-taping to the roof of
  197. any vehicle.  The uside down cake pans are reasonably aerodynamic and support
  198. both the GPS antenna and a 19 inch 2 meter whip.  A single power cable
  199. extended down the windshield and was clipped directly to the vehicle battery.
  200. The package could be moved to another vehicle in about five minutes.  The
  201. cake pan included only a walkie talkie transmitter at about the one watt
  202. level.
  203.  
  204.     Since we only have two WIDE area APRS digipeaters in the state, and the
  205. CAM tour never went near them, we were dependent on home stations all across
  206. the state to serve as digipeaters for the event.  The GPS packages were set
  207. to digipeat via the WIDE,WIDE path.  By setting the alias of all home
  208. stations along the route to be WIDE, the vehicles were never beyond range of
  209. at least one WIDE station.  Since the outgoing GPS packets were set up for
  210. WIDE,WIDE, the second digipeat was always picked up by one of the existing
  211. permanent WIDE digipeaters so that stations throughout the state could see
  212. the position of the one watt GPS units!  We were looking for home stations
  213. about every 10 miles.  Of course, as soon as a station was passed and was no
  214. longer in direct contact with the GPS units, it was IMPORTANT to remove the
  215. WIDE alias to minimize duplicative repeats.  For this seven day event, home
  216. stations were organized on a nightly basis.  Assigned stations would be WIDE
  217. for a whole day so that operators did not have to be home during working
  218. hours.
  219.  
  220.      As an added technique, we also set up both GPS units with the alias
  221. of WIDE so that they would also help digipreat each other along the trail.
  222. The disdavantage of this technique was evident as both vehicles returned to
  223. the evenings command post (also WIDE) and you had three WIDE digipeaters in
  224. 100 yards of each other!  It was noisy within local simplex range of that
  225. site, but stations all over the state still saw the packets via the permanent
  226. WIDE digipeaters.  Eighty percent of the home stations used as WIDE
  227. digipeaters had never even heard of APRS.  They simply heard about the need
  228. for home packet stations and only had to change their ALIAS (and frequency)
  229. as directed by local announcements posted on all area BBS's.
  230.  
  231.      The event was an exciting success!  Occasionaly there were not enough
  232. HAM voice operators per day to have HAMS in all of the relief vehicles.  When
  233. ever a shortage occurred, the HAMS were removed from the GPS vehicles and
  234. assigned elsewhere.  The location of the GPS vehicles were always known by
  235. net control via the APRS system so the need for a HAM rider was not necessary
  236. and in fact, only took up valuable space.  Whenever voice communications were
  237. needed with the GPS relief vehicle, a mobile HAM was directed to the location
  238. indicated on the APRS screen.
  239.  
  240. SYMBOLS:  During the 94 MS Bikethon in Northern Virginia, KD4SJJ noticed that
  241. with four GPS mobiles and several fixed stations along the route, that there
  242. were so many callsigns that you could not see the map.  He suggested making
  243. several numbered symbols so that all stations could be distinguished even
  244. with CALLSIGNS off!  This was such a good idea, that not only did we make
  245. lettered balls (A-J) for the mobiles, but we also made square boxes 0-9 for
  246. the fixed stations!  With these tactical symbols, and callsigns off, the map
  247. display is improved by an order of magnitude.  Also added in 5.03a were an
  248. additional 7 different mobile symbols for various vehicle types!
  249.  
  250. EMISSION CONTROL:  If there are only a few APRS stations involved in an event
  251. but there are lots of APRS observers on frequency, then the observers can set
  252. their transmitter off using the CONTROLS-X command.  That way they minimize
  253. QRM on channel.  While the transmit function is disabled, a one-time
  254. transmission can be forced each time the X key is pressed.  The X key
  255. enables one cycle of APRS transmission which may contain up to four packets
  256. containing your Beacon, Position, Objects, or Messages.  You can send only
  257. your MESSAGES by simply hitting the T (TRAFFIC) key once.
  258.  
  259. LOAD SHARING:  Since any station can take over reporting of any objects, one
  260. approach is to let only one station hook every symbol that comes in and then
  261. he becomes the reporting repsonsibility.  The original station that uplinked
  262. the report in the first place will fall silent when it sees the report
  263. comming from the designated Net Control station.  This way all positions are
  264. reported by only one station on frequency, although all other stations can
  265. still update the positions as needed.  Remember that the last station to
  266. report the position of an object will be the one that continues to report it!
  267.  
  268.  
  269. MARINE CORPS MARATHON:  See the README.MCM for details and lessons learned
  270. using APRS at the Marine Corps Marathon on 24 October in Washington DC.
  271.  
  272.